home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Floppyshop 2
/
Floppyshop - 2.zip
/
Floppyshop - 2.iso
/
diskmags
/
0022-3.564
/
dmg-0055
/
605.txt
< prev
next >
Wrap
Text File
|
1997-04-16
|
12KB
|
308 lines
INFO-ATARI16 Digest Sat, 4 Nov 89 Volume 89 : Issue 605
Today's Topics:
>everybody would agree that it is VaporWare.
certain incorrect rumors
GNU C and sizeof(int) (2 msgs)
Hard Drive RLL info... Good Deal?
Problematic internal drives.
questions, questions, questions
TOS 1.4 Incompatibility List: Populous
TT's VME-slots (2 msgs)
----------------------------------------------------------------------
Date: Thu, 02 Nov 89 18:57 CST
From: jeff beer <UUCJEFF%ECNCDC.BITNET@UICVM.uic.edu>
Subject: >everybody would agree that it is VaporWare.
>
>Atari has a long history of VaporWare. Remember the ST that was going to use
>the 68020 cpu?? It never came out either.
>
Well in all fairness, they decided the 68020 did not improve performance
over the 68000 that much so why bother. Goto the 68030 instead.
No sense in putting out something that is not much of an improvement.
But they do have problems in getting their other stuff out on schedule.
Jeff Beer, chicago
------------------------------
Date: 4 Nov 89 06:15:48 GMT
From: microsoft!w-darekm@uunet.uu.net (Darek Mihocka)
Subject: certain incorrect rumors
If Andrew Semple is reading this...
Three attempts to reply to your email this week were bounced back by watmath.
Seems you don't exist! Either try a different path, or leave me a voice #.
Hope the subject of this message answers your question.
- Darek
------------------------------
Date: 4 Nov 89 05:26:45 GMT
From:
swrinde!cs.utexas.edu!usc!samsung!shadooby!mailrus!jarvis.csri.toronto.edu!utgp
u!watmath!ria!uwovax!7103_300@ucsd.edu
Subject: GNU C and sizeof(int)
In article <28772@shemp.CS.UCLA.EDU>, stephen@oahu.cs.ucla.edu (Steve Whitney)
writes:
> In article <30975@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray
Butterworth) writes:
>
>>Has anyone made a 16-bit GCC and library and done a comparison?
>
> You can always use this simple hack:
>
> #define int short
> [ more useful hints deleted ]
>
Your suggestions are fine, but the easiest solution is to get the 16 bit
libraries (and a version of the compiler that can handle them; anything
later than 1.34, but I'd recommend getting 1.36). I routinely use -mshort
with no problems (other than brain-damaged software that thinks
sizeof(int) == sizeof(long); but the prototypes in the standard include
files help a lot with even that).
The most up-to-date version of the libraries (both 16 and 32 bit) are
available on dsrgsun.ces.cwru.edu, in ?ftp/atari. If you don't have
these libraries, get them; thanks to some nice work by Dale Schumacher
(dLibs), Henry Spencer (strings), Jwahar Bammi (lots of stuff), the
people at Berkeley (curses and doprnt) and yours truly, they're a big
improvement on the original GCC library.
Eric R. Smith
ersmith@uwovax.uwo.ca
------------------------------
Date: 4 Nov 89 01:54:45 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: GNU C and sizeof(int)
rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>In article <1754@ruuinf.cs.ruu.nl> piet@cs.ruu.nl (Piet van Oostrum) writes:
>>Dlibs and Gemfast have been written for a 16 bit compiler.
>>I have a version of Dlibs that I adapted for use with GCC.
>>It has been modified for 32 bit integers.
>Why does GCC on the ST have 32 bit ints?
It also has 16-bit ints: use -mshort on the command line.
> "so that badly written code will still work ok"
I *do* consider this a valid reason. Personally, I consider "int" to
be an evil data type when the issue of portability comes up. But look
at UNIX and all the libraries meant to look like UNIX: malloc, fwrite,
etc. all take "int" arguments, because "int" is "big enough" on those
machines. A 16-bit library will probably work, but you can't malloc /
write more than 32K at a time. Thanks. MWC suffers from this, as does
Alcyon and some Mac-derived compilers (but for a different reason).
It's not pretty, but we're stuck with it. If you don't want it to be
slow, use "short." (Unless your compiler is REALLY bad, like MegaMax's
is or was, and "short" is *8* bits!)
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 4 Nov 89 10:40:11 GMT
From:
cs.utexas.edu!samsung!uakari.primate.wisc.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.
uiuc.edu!uxa.cso.uiuc.edu!uxf.cso.uiuc.edu!glk3593@tut.cis.ohio-state.edu
Subject: Hard Drive RLL info... Good Deal?
I am buying/have ordered from my dealer a 30 meg RLL hard
drive in an expandable case with a 40ms access time MiniScribe
drive. Any comments on the price of $600? He's giving me the
offer of $300 down and $100/month for the following three months.
Any comments on the drive/ICD controller would be very much appreciated
He said he is not using SCSI or something like that since getting
a second drive would be cheaper later...
Thanks in advance for any e-mail or responses. (I do read
this news-file)
-Spieu!
------------------------------
Date: 4 Nov 89 10:40:09 GMT
From:
cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!uwm.edu!ux1.cso.ui
uc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!uxf.cso.uiuc.edu!glk3593@tut.cis.ohio-s
tate.edu
Subject: Problematic internal drives.
I had the same problem with my 2 year old 1040. What I did is
open the case (after trying the same things you did...).
Turns out my disk drive was full of dust. I brushed it all
off, took the rectangle mech. out of the case and cleaned it.
Now everything works.
One other thing to watch for is placement of your monitor.
Atari's monitors emit an exorbitant emf field which can
royally @%#! over your drive's operation. i.e. if it is
placed anywhere over the drive..
-Spieu!
------------------------------
Date: 3 Nov 89 20:28:52 GMT
From: hp-pcd!hplsla!andyc@hplabs.hp.com (Andy Cassino)
Subject: questions, questions, questions
|As I said, I don't use Interlink but I have friends who swear by
|it. Maybe someone else can explain Interlink.
|
|Richard Covert
|----------
I have been using Interlink for about 3 months.
I give Interlink an "okay" rating. I bought Interlink because it is GEM
based (didn't realize Flash was GEM based). But, the GEM interface is not
well thought out in a couple of areas and so is a mixed blessing. (At least,
the organization of the menus doesn't make too much sense _to_me_). It is
hard to figure out where to find things in some cases. I end up using
the function keys much of the time.
Other notes:
The learn mode works but you can't edit the resultant script (at least
not officially). Maybe the file is editable, I haven't looked.
The manual is comprehensive but it is hard to find things (the index is
not very complete). I learned alot about "telecommunications" from it,
though. It bears several readings if you are new to modems and such.
The program has lots of esoteric (for me) features, so I doubt I'll need
a program that does more. I would guess that most anyone can do what they
want with this program.
The code seems fairly robust. I've had trouble with running programs during
background downloads, and I had trouble when I set the fast bit. Otherwise,
the code seems very solid.
The program came with a free Genie sign-up, so I effectively paid $5 for it.
Summary: I'd have a closer look at Flash if I were to do it again. But
I intend to keep on using Interlink now that I have it. It does what I need
and does it reliably. I may upgrade to Masterlink to gain scripting
and improved background download capabilities though.
Disclaimer: The opinions expressed herein are those solely of the author,
who has no pecuniary interest in the companies mentioned.
Copyright (c) 1989 by Andrew Cassino.
Permission for distribution on USENET hereby granted.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Andy Cassino %
% uucp: hplabs!hplsla!andyc domain: andyc%hplsla@hplabs.hp.com %
% Hewlett-Packard Lake Stevens Instrument Division %
% 8600 Soper Hill Road Everett, WA 98205-1298 %
% (206) 335-2211 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
------------------------------
Date: 4 Nov 89 03:03:49 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher)
Subject: TOS 1.4 Incompatibility List: Populous
in article <267@mirsa.inria.fr>, colas@trinidad.inria.fr (Colas Nahaboo) says:
>
> Yes, Most of the greatest ST games do not work with TOS 1.4: Populous,
> dungeon master, Falcon, Rick Dangerous...
- ~~~~~~~~~~~~~~ -
I find this quite hilarious. In fact, we had to MODIFY a change we
made for Rainbow TOS so that Dungeon Master would WORK!
Heeeheeheheheh.
Dungeon Master most assuredly works on Rainbow TOS.
So do Populous and Falcon and Rick Dangerous.
As to the other comments, I hope that every cracked game in existence
fails on Rainbow TOS.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
Date: 4 Nov 89 06:37:38 GMT
From: oahu!stephen@cs.ucla.edu (Steve Whitney)
Subject: TT's VME-slots
In article <2471@odeon.ahse.cdc.com> bga@odeon.ahse.cdc.com (Bruce Albrecht)
writes:
>In article <1771@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes:
>> Remember (as has been pointed out before) no vendor HAS to design
>> hardware specifically for that slot: it's already been done. That's
>> why we chose a standard bus interface.
>
>Only part of the design process is the hardware. If the vendor doesn't see
>the TT as a large enough market, the customer will have to write the device
>drivers, which would be a major undertaking for the average TT owner.
Of course, this opens up a new "fourth party" market. Just as there are
HP laserjet, deskjet, and postscript GDOS drivers, if there's a large
enough market, an Atari developer will write and market a driver. This
developer might even sell the card as a value added package. At least,
he/she would not have to do hardware development to put out something
like a NetBIOS for the TT...
--Steve
Steve Whitney "It's never _really_ the last minute" (())_-_(())
UCLA Comp. Sci. Grad. Student | (* *) |
Internet: stephen@cs.ucla.edu UCLA Bruin--> ? \_@_/ ?
GEnie: S.WHITNEY `-----'
------------------------------
Date: 4 Nov 89 03:08:53 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher)
Subject: TT's VME-slots
covertr@force.UUCP (Richard E. Covert) writes:
| Actually, the TT
| sounds like one hell of a GOOD Game Machine!! IT should be
| marketted as such!!!
Richard, you are confused. Sure, some really hot games will probably come
out for TT. And despite the fact that TT will be _very_ reasonably priced,
it won't quite be priced in the range of game machines.
Get real, guy.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
End of INFO-ATARI16 Digest V89 Issue #605
*****************************************
=========================================================================